fix(cli): port functions download to native TypeScript (CLI-1963) - #6082

Ports `supabase functions download`'s default Docker-unbundle path
(`--use-docker`, default true) from wholesale Go-binary delegation to
native TypeScript, in both the legacy and next shells. `--use-api` was
already native; `--legacy-bundle` (hidden, deprecated pre-1.120.0
fallback requiring a host Deno-binary install with no precedent
elsewhere in this codebase) is deliberately left delegating to the Go
binary, per the parity-audit rationale recorded on the Linear issue.

Hoists the Docker-orchestration primitives `download.ts` needs
(`runChildProcess`, `isDockerRunning`, `ensureDockerNetwork`,
`ensureDockerNamedVolume`, `localDockerId`, `resolveEdgeRuntimeVersion`,
etc.) out of `deploy.ts` into a new `functions-docker.ts`, and
deduplicates the `edge-runtime-version` pin file lookup that was
copy-pasted across all four `deploy`/`download` handler files into a
single `resolveEdgeRuntimeVersionPin` helper.

Along the way, fixes:
- CLI-1891-class validation gap: slugs sourced from the Management
  API's function list weren't validated before the new Docker path's
  temp-file write, reopening a path-traversal vector Go's own
  `downloadAll` already guards against.
- The `next` shell's `--use-docker` flag was missing `Flag.withDefault(true)`,
  a real default-value divergence from both `legacy` and Go.
- A brotli-decompression bug: this CLI's HTTP transport already
  auto-decodes `Content-Encoding: br` responses (confirmed empirically),
  so re-running `brotliDecompressSync` on the eszip body threw on
  already-decoded bytes.
- Temp eszip cleanup only ran after a successful Docker run; wrapped in
  `Effect.ensuring` so it also runs on network/volume/spawn failures,
  matching Go's `defer`.
- The `.suggestion` field's leading newline (needed to reproduce Go's
  blank separator line before the `--legacy-bundle` hint) was being
  trimmed away by the generic CLI error normalizer.

…view: CLI-1963)

Go's DockerStart only overrides the Docker network when
len(viper.GetString("network-id")) > 0 (internal/utils/docker.go:379-382).
The native functions download/deploy Docker paths used
explicitStringFlag(...) ?? localDockerId(...), which returns "" (not
undefined) for --network-id=, so an explicit empty override was invoked
verbatim instead of falling back to the generated network.

Adds explicitNonEmptyStringFlag (cobra-flag-groups.ts), which folds in Go's
len(value) > 0 gate, and switches both download.ts and deploy.ts's docker
network resolution to it.

… mode (review: CLI-1963)

Go's container.NetworkMode.IsUserDefined() explicitly excludes IsContainer()
(docker/api/types/container/hostconfig_unix.go:23-25), so DockerNetworkCreateIfNotExists
never inspects or creates a network for --network-id container:<name|id> — the mode
attaches to another container's stack and is passed straight through to `docker run
--network`. The shared isUserDefinedDockerNetwork predicate (used by deploy.ts,
serve.ts, download.ts, and start's container lifecycle) didn't exclude this case, so
the Docker download path's preflight would have run `docker network inspect`/`create
container:redis` before `docker run`. Fixed once in the shared predicate so every
consumer gets the same fix.

…3-port-functions-download-to-native-typescript-both-shells

# Conflicts:
#	apps/cli/docs/go-cli-porting-status.md

… gaps (review: CLI-1963)

Codex flagged that resolveEdgeRuntimeImage falls back to the v2 default
when config.toml is absent (ignoring SUPABASE_EDGE_RUNTIME_DENO_VERSION),
and that networkMode resolution never checks SUPABASE_NETWORK_ID the way
Go's viper AutomaticEnv does for the --network-id persistent flag.

Both are confirmed real gaps, but pre-existing and cross-cutting rather
than introduced here: deploy.ts has the identical deno_version fallback
today (config.toml present or not, since @supabase/config has no generic
env-var struct binding at all), and start.handler.ts/deploy.ts/serve.ts's
own network-id resolution don't check SUPABASE_NETWORK_ID either. Fixing
either belongs in one shared place, not duplicated per Docker-path call
site in download.ts alone -- left open, matching this PR's existing
precedent for the registry-fallback gap. Documented inline and in the PR
description's "Judgement calls left open" section instead of silently
resolving the review threads.

… flag (review: CLI-1963)

pflag/viper string flags are shared-variable, last-Set()-wins (confirmed
empirically with a scratch pflag.FlagSet.Parse probe: --network-id old
--network-id ci-net resolves to ci-net; a trailing --network-id= clears an
earlier non-empty value). explicitStringFlag returned on the first argv
match instead of scanning for the last, unlike this file's own
explicitBooleanLongFlag and the legacy shell's legacyPflagStringValue,
which already implement last-wins. Fixed to keep scanning, plus regression
tests covering the repeated-override and repeated-then-cleared cases.

…review: CLI-1963)

resolveEdgeRuntimeImage() (and its config.toml/config.json read) runs
unconditionally after resolving the project ref, before the --use-api
check -- matching Go's flags.LoadConfig running unconditionally at the
top of Run. The doc previously claimed --use-api reads no project
config at all, which is now stale.

Also documents BITBUCKET_CLONE_DIR: the new Docker-unbundle path skips
creating the named Deno-cache volume and its bind mount when set,
mirroring deploy.ts's existing carve-out; the Environment Variables
table omitted it entirely.

…ug (review: CLI-1963)

Go's generated client unmarshals the entire []FunctionResponse array in one
json.Unmarshal call (apps/cli-go/pkg/api/client.gen.go:22186-22208) -- a type
mismatch on any single element's slug (a required string field) fails that
call outright, and ParseV1ListAllFunctionsResponse returns before ever
assigning response.JSON200, so downloadAll fails with "failed to list
functions: ..." before downloading anything. listRemoteFunctionSlugs instead
coerced a present-but-non-string slug (e.g. 123) to "", so an earlier
well-formed entry in the same list would already be downloaded before the
later entry's validation error surfaced. Throw immediately on a present,
non-string slug (still zero-valuing missing/null, matching Go's
null-into-non-pointer no-op) to preserve Go's fail-before-any-download
ordering. Confirmed empirically with a scratch json.Unmarshal probe.

…g (review: CLI-1963)

resolveEdgeRuntimeImage calls legacyGetRegistryImageUrl with no
projectEnvValues, so a SUPABASE_INTERNAL_IMAGE_REGISTRY set only in
supabase/.env (not the ambient shell) is invisible here, unlike Go's
flags.LoadConfig -> loadNestedEnv, which os.Setenvs every project dotenv key
into the process env before GetRegistry() ever reads it. Confirmed real, but
pre-existing and cross-cutting, not specific to this PR: deploy.ts and
serve.ts call the same helper the same way -- the only caller that resolves
and threads project dotenv today is start, via legacyLoadLocalProjectContext.
Belongs in the shared config-loading layer every native functions Docker
path goes through, not duplicated per call site -- left open, same treatment
already applied to the registry-fallback/config-defaults/network-id-env/
Config.Validate gaps in this same function.

… (review: CLI-1963)

- edge-runtime-version pin is read unconditionally by
  resolveEdgeRuntimeVersionPin() before the --use-api/Docker choice, not
  only on the Docker-unbundle path.
- goViperCompat's tomlOnly:true means config.json is never a legacy read
  path; drop the "(or config.json)" implication from config.toml's row.
- list the SUPABASE_INTERNAL_IMAGE_REGISTRY env var, read unconditionally
  while resolving the edge-runtime image (even on --use-api invocations).

…download/serve (review: CLI-1963)

- extract shared one-shot docker-run builder (binds/network/env/labels) used by
  deploy's bundler and download's unbundler; both containers now carry Go's
  com.supabase.cli.project/com.docker.compose.project labels
- stream container stdout/stderr live via runChildProcess onStdout/onStderr
  tees instead of buffering until exit (Go DockerStreamLogs parity)
- resolve edge-runtime images through the ECR->GHCR->Docker-Hub retry resolver
  (legacyMakeDockerImageResolver) in deploy, download, and serve
- fix v-prefix double-tagging via shared edgeRuntimeImageTag helper
- fold serve's own edge-runtime version-pin lookup into the shared
  resolveEdgeRuntimeVersionPin/resolveEdgeRuntimeVersion helpers
- add loadFunctionsProjectConfig + legacyFunctionsGoConfigCompat: legacy-shell
  functions Docker paths now run the same dotenv/Config.Validate pipeline as
  start/stop/status (template defaults + env with no config.toml, project_id
  validation, project dotenv threaded into registry resolution)
- honor SUPABASE_NETWORK_ID (ambient env + project dotenv) for network
  selection via resolveDockerNetworkMode, preserving viper's changed-flag
  precedence
- style the 'Docker is not running' WARNING: prefix yellow via injected
  styleWarning hook in both shells' deploy/download
- refresh the stale next/ functions section in go-cli-porting-status.md

…eview: CLI-1963)

- use context.projectId (remote-override-gated, --project-ref defaulted,
  sanitized) for the functions Docker paths instead of the validation-only
  projectId, restoring the [remotes.<ref>] OVERRIDE-tier guard for
  SUPABASE_PROJECT_ID
- apply edge-runtime version pins VERBATIM as image tags (Go replaceImageTag
  semantics) via a single edgeRuntimeImage helper sourced from the Go
  Dockerfile — no more v-prefix synthesis that broke bare pins like 'latest'
  and disagreed with legacy-edge-runtime-image.ts over the same pin file
- consolidate --network-id resolution into resolveDockerNetworkMode: delete
  legacyResolveNetworkId, whose explicit-empty-flag handling wrongly fell
  through to SUPABASE_NETWORK_ID (viper resolves a Changed pflag before env);
  start/db start now use the shared helper
- replace explicitStringFlag with the stronger existing
  lastExplicitLongFlagValue (handles '--' terminator, consumed value tokens,
  trailing valueless occurrences); drop hasGlobalLongFlag and gate deploy's
  bundler --verbose on explicitBooleanLongFlag so --debug=false disables it
- pass Go's bundler WorkingDir (-w) through the shared docker-run builder;
  sanitize next-shell project ids before they reach container labels
- scope runChildProcess so per-invocation spawn finalizers don't accumulate
  across functions serve restarts
- decouple integration tests from @supabase/stack's DEFAULT_VERSIONS (assert
  against the Go Dockerfile image); make hidden-flag's --use-docker probe fail
  pre-Docker so a live CI daemon can't trigger a real image pull
- add streaming-tee unit tests (split multi-byte UTF-8, no empty chunks),
  explicitBooleanLongFlag cases, and bundler label/workdir assertions
- document the BITBUCKET_CLONE_DIR process.env install in deploy/serve
  SIDE_EFFECTS.md and correct serve's no-env-mutation claim

…stions (review: CLI-1963)

Go's suggestDenoV2 bolds the config path (utils.Bold(utils.ConfigPath))
and downloadAll's slug-validation suggestion wraps the slug in
utils.Aqua — both rendered plain in the TS port. Thread the existing
styleEmphasis/styleAqua hooks through so the legacy shell matches byte
for byte; next stays plain via the existing identity-fallback.